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PREFACE 

The TMIS Life-Cycle Process Document, SSP 30542, provides an overview and general 
guidance on the phases and activities that comprise the life-cycle process as applied to 
the procurement and/or development of Programwide technical and management data 
processing products and data base applications. 

This document contains an introduction and subparagraphs on TMIS life-cycle process 
concepts, TMIS life-cycle activities, major TMIS reviews, documentation, and 
implementation of TMIS life-cycle process. 

The contents of this document are intended to be consistent with the tasks and products 
to be prepared by NASA Work Package Centers and Space Station Freedom Program 
(SSFP) participants as defined in SSP 30000, Space Station Program Definition and 
Requirements Document. The TMIS Life-Cycle Process Document shall be 
implemented on all new SSFP contractual and internal activities and shall be included in 
any existing contracts through contract changes. This document is under the control of 
the Space Station Control Board, and any changes or revisions will be approved by the 
Deputy Director. 


R. W. Moorehead /s/ 


11/18/91 


Deputy Director, 

Space Station Freedom Program and Operations 


Date 
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1.0 INTRODUCTION 

The TMIS Life Cycle Process Document describes the processes that shall be followed in 
the definition, design, development, test, deployment, and operation of all Technical and 
Management Information System (TMIS) products and data base applications. This 
document is a roll out of TMIS Standards Document (SSP 30546). 

1.1 PURPOSE 

The purpose of this document is to define the life cycle methodology that the developers 
of all products and data base applications and any subsequent modifications shall follow. 
Included in this methodology are descriptions of the tasks, deliverables, reviews, and 
approvals that are required before a product or data base application is accepted in the 
TMIS environment. 

1.2 SCOPE 

The TMIS Life Cycle Process Document provides an overview of the phases and 
activities that comprise the life cycle process as applied to the procurement and/or 
development of Program wide technical and management data processing products and 
data base applications. These include commercial-off-the-shelf (COTS) system 
software, application software packages, hardware, and network components, as well as 
data base applications that are procured and/or developed to support the Space Station 
Freedom Program (SSFP). The TMIS Life Cycle Process Document shall not apply to 
Flight Software. 

Programwide technical and management data processing products and data base 
applications are defined as all those to be shared among SSFP levels I, EL, and IH; NASA 
centers; other organizations; and International Partners in support of SSFP activities. 

The TMIS Life Cycle Process Document is intended to provide general guidance on the 
phases and activities to be incorporated into the procurement and/or development of 
Program wide data processing products and data base applications. This document will 
be maintained as a TMIS baseline document; a series of enabling procedures, described 
in Section this document, will be maintained as part of the TMIS Policy and Procedures 
Manual. 

Developing organizations are responsible for creating or modifying their internal 
operating procedures so that they are in accordance with the TMIS Life Cycle Document 
and the TMIS Office Enabling Procedures. 

1.3 PRECEDENCE 

In case of conflict between this document and SSP 30000, Space Station Program 
Definition and Requirements Document, the requirements of SSP 30000 take 
precedence. 
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1.4 DELEGATION OF AUTHORITY 

This document is the responsibility of the Space Station Freedom Program Office 
(SSFPO), TMIS Office. This document is subject to Level II TMIS Control Board 
change control. 


1.5 WAIVER/DEVIATION 

Any request for waiver or deviation from this standard shall be made to the SSFPO, 
TMIS Office, in accordance with SSP 30000 Section 2 Part 9. 



SSP 30542 Revision A 


2.0 DOCUMENTS 

The following documents of the date and issue form a part of this document to the extent 
specified herein. “(Current Issue)” is shown in place of the specific date and issue when 
the document is under Level II TMIS Control Board control. The current status of 
documents shown with “(Current Issue)” may be determined from the SSCB Executive 
Secretary or from the Baseline Activity Index and Status Report available in SSFPmail. 


2.1 APPLICABLE DOCUMENTS 

The documents in this paragraph are applicable to the extent specified herein. 

DOCUMENT NO. TITLE 


SSP 30000 Section 8 
(Current Issue) 
Reference 


PDRD, Technical and Management Information System 
Paragraph 1.3 


Section 2 Part 9 
(Current Issue) 
References 


Configuration Management Requirement 


Paragraphs 1.5, 4. 1.3.3 


SSP 30535 
(Current Issue) 
References 


TMIS Information Engineering Methodology (TEEM) 


Paragraphs 4.1, 4. 1.3.1, 5.5.1 


SSP 30536 
(Current Issue) 
References 


TMIS User Documentation Style Guide 


Paragraphs 4. 2.3.4, 4.2.3.6, 5.5.1 


SSP 30541 
(Current Issue) 
References 


TMIS Security Requirements 


Paragraphs 4. 2.3. 5, 5.5.1 


SSP 30543 
(Current Issue) 
Reference 


TMIS Application Development Standards 


Paragraph 5.5.1 


BB 000949 A 
References 


Program Function Model 
Paragraphs 4.0, 4.1 


N/A 

Reference 


TMIS Procedure 90-01, Security Certification 
Paragraph 4. 2.3. 5 
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N/A 

TMIS Problem Reporting Enabling Procedure 

References 

Paragraphs 4. 1.3. 4, 4.3.2, 5.5.2 

N/A 

TMIS System Certification Enabling Procedure 

References 

Paragraphs 4.2. 1.3, 4.2.1.5, 4.2.1.6, 5.5.2 

TSS 30551 

SSFP Data Naming Standards 

Reference 

Paragraph 5.5.1 

BB000851C 

Program Data Model 

Reference 

Paragraph 4. 2. 1.1 

N/A 

TMIS Life Cycle Process Management Enabling 
Procedure 

References 

Paragraphs 4.2.3. 1, 5.1, 5.4, 5.5.2, 5.5 

N/A 

TMIS Documentation Management Enabling 
Procedure 

References 

Paragraphs 4.2.3.2, 4.23.3, 4.23.5, 4.3.3.4, 4.4. 1.1, 
4.4.2,4.43.1,4.4.3.2, 5.5.2 

N/A 

TMIS Host System Standards Enabling Procedure 

References 

Paragraphs 4.23.5, 5.5.2 

N/A 

TMIS Configuration Management and Product 
Assurance Enabling Procedure 

Reference 

Paragraph 5.5.2 
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3.0 LIFE CYCLE PROCESS MODEL 

Figure 3.0-1 The TMIS Life Cycle Process Model consists of five elements: 

— Phases 

— Processes 

— Reviews 

— Documentation and Software 

— Supporting Facilities 

Each of the model elements is further described below. 

3.1 PHASES 

The end-to-end time frame of a TMIS product spans the following five sequential 
phases of activity: 

— Requirements Phase 

— Design and Development Phase 

— Test Phase 

— Deployment Phase 

— Operational Phase 

The modification of an operational system will follow this same sequence of activities. 
These phases are further described in Section 4 of this document. 

3.2 PROCESSES 

Each phase of the TMIS life cycle process model consists of one or more processes. 

These processes are described in detail in Section 4 of this document. 

3.3 REVIEWS 

Technical reviews are significant to the continuation of subsequent processes or 
installation. These reviews are further described in Section 4 of this document. 

3.4 DOCUMENTATION AND SOFTWARE 

Within each phase, and generally related to one of the processes, documentation or 
software outputs are identified. The specific descriptions are included in Section 4 of 
this document. 

3.5 SUPPORTING FACILITIES 

As an adjunct to preparing, collecting, and storing life cycle outputs, several physical and 
electronic media facilities are employed and configuration managed to ensure the 
integrity and retention of life cycle deliverables. These facilities are described in 
Section 4 of this document. 
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4.0 LIFE CYCLE PROCESS DESCRIPTION 

The decision to undertake development or addition of a TMIS product shall be made as a 
result of a tactical planning process that aligns TMIS capabilities and resources with 
support for critical Space Station Freedom Program functions. The totality of these 
functions is represented in the Program Function Model (PFM). The PFM is the starting 
point for identifying and prioritizing development activities that support SSFP functions 
in each phase of the SSFP life cycle. Once a need has been determined and prioritized 
within the context of the PFM, the ensuing development process enters the sequence 
described in this TMIS Life Cycle Process Document. 

The TMIS implementation philosophy emphasizes the importance of having 
user-representatives intimately involved throughout the requirements, design and 
development, and testing phases. While the phases of the life cycle process are 
sequential, their relative duration will depend on the complexity and number of activities 
that will take place within each phase. 

The following paragraphs describe each phase of the TMIS life cycle process as well as 
the other model elements (i.e., processes, reviews, and deliverables) and are keyed to the 
model elements shown in Figures 4.0-1 and 4.0-2, TMIS Life Cycle Process 
Model - Process Flow Diagram. 


4.1 REQUIREMENTS PHASE 

The objective of the Requirements Phase is to establish a definitive statement of 
requirements for a product or data base application. The need for the product or data 
base application shall be identified prior to the Requirements Phase through the tactical 
planning process, which utilizes the Program Function Model. An SSFP Office of 
Primary Responsibility (OPR) shall be identified to further specify the requirements for 
the product. Appendix A of SSP 30534 contains the definition of an OPR. 

Documentation of the requirements may take the form of a Detailed Functional 
Requirements Document (DFRD) or a Requirements Definition Document (RDD). The 
requirements may be derived from the SSFP Program Function Model, an information 
system need identified by an SSFP Office of Primary Responsibility, or a required 
contract deliverable. The requirements must be defined and documented such that the 
resulting product can be verified against the requirements. Formal review and joint TMIS 
Office/developer/OPR approval of the requirements and resource allocation is necessary 
before proceeding into the design and development phase. 


4.1.1 REQUIREMENTS DEFINITION PROCESS 

Requirements definition is the first process of the TMIS life cycle. This process involves 
the identification, analysis, and documentation of requirements that describe a TMIS user 


4-1 



SSP 30542 Revision A 


need. This process also involves the definition of the overall concept, strategy, and scope 
associated with the TMIS component. The importance of this first process lies in the fact 
that the defined requirements form the basis for all subsequent life cycle activities. 

The objective of the requirements definition process is to define and document a set of 
testable and verifiable requirements that address all aspects of the desired product 
including, but not limited to, functional requirements, data requirements, and operating 
system requirements. 

Definition of requirements is accomplished through the combined interactions of the 
TMIS Office, the contractor responsible for development of the product, and 
representatives of the sponsoring Office of Primary Responsibility. 

The requirement for a new product or data base application is documented in a 
Requirements Definition Document (RDD) or Detailed Functional Requirements 
Document (DFRD). Changes to an existing product or data base application are 
documented in a Change Request (CR) written against an existing RDD or DFRD. 
Discrepancies or problems with a product or data base application are documented in a 
Problem Report (PR) and constitute a requirement to make changes to an as built product 
to bring it in line with an RDD or DFRD. 

4.1.2 REQUIREMENTS REVIEW 

The requirements document is generated, reviewed, and approved by the TMIS Office, 
the contractor responsible for the development of the product, and the user community as 
appointed by the Office of Primary Responsibility. 

This review occurs after the requirements have been defined and documented. Approval 
of the requirements signifies that the TMIS Office, the Office of Primary Responsibility 
representative, and the developer endorse the requirements as valid and in agreement 
with SSFP/TMIS standards and that approval to proceed with implementation is 
authorized. The requirements documents shall be made available to the reviewers ten 
working days prior to the requirements review. Requirements are then submitted to the 
TMIS Control Board for baselining. 

Implementation of the product or data base application addressing the approved 
requirements may be facilitated by one or more production deployments (i.e., a phased 
implementation). All requirements that are approved by the TMIS Office and baselined 
by the TMIS Control Board have been reviewed and.are deemed reasonable, 
implementable, and affordable by TMIS. 

4.1.3 REQUIREMENTS DOCUMENTATION 

The principle product of the requirements phase is a definitive description of a required 
component as compiled in a formal requirements document. This requirements 
document may take one of several forms as described in the following paragraphs. 
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4.1. 3.1 REQUIREMENTS DEFINITION DOCUMENT 

The TMIS RDD is used to document application requirements defined in this life cycle 
phase. The RDD is defined in Appendix A of the TMIS Information Engineering 
Methodology (T1EM), “Annotated Outline,” as baselined, by the TMIS Control Board. 
This format shall be followed when the requirement is derived from development tasks 
related to the Program Function Model. 

Upon approval following the requirement review process, the RDD is submitted to the 
TMIS Control Board to be baselined. 

4.1. 3.2 DETAILED FUNCTIONAL REQUIREMENTS DOCUMENT 

In the case of vendor-provided or commercial-off-the-shelf (COTS) products, the 
requirements shall be documented in a TMIS DFRD and baselined by the TMIS Control 
Board. In this case, the requirement is documented in an extraction of applicable product 
documentation along with supporting technical specifications. 

4.1. 3.3 CHANGE REQUESTS 

The process for documenting a Change Request (CR) is defined in SSP 30000 Section 2 
Part 9. 

4.1. 3.4 PROBLEM REPORTS (PR) 

The process and format for documenting a problem with an operational TMIS product or 
data base application is defined in the TMIS Problem Reporting enabling procedure. 

4.2 DESIGN AND DEVELOPMENT PHASE 

The objective of the Design and Development Phase is to design and develop a product 
or data base application that satisfies the defined requirements. Based upon the 
documented requirements, a make/buy decision will be made resulting in either the 
preparation of a product specification to be released for competitive procurement, the 
assignment of a design and development task to a development organization, or a 
combination of the two. Current procurement procedures will be followed if a decision is 
made to purchase the product. The end result of this phase is a product that has been 
developed to satisfy the documented requirement and is ready for test and formal 
certification. 

4.2.1 DESIGN AND DEVELOPMENT PHASE PROCESSES 

4.2.1. 1 DESIGN/SPECIFICATION PROCESS 

The TMIS life cycle emphasizes an iterative process toward the accomplishment of the 
design and development of the product. The activities associated with this phase involve 
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both the logical and physical design of the product. Where applicable, the design of the 
product is reviewed against the global TMIS models (e.g., the TMIS Program Data 
Model ICDs) to ensure the feasibility and viability of the proposed design. Ensuring the 
integration of the product with other products, existing and planned, is of prime 
importance during this design activity. 

A product architectural design shall be established prior to beginning any unit code 
development. At a minimum, this architectural design for data base applications shall 
include the logical data model and the associated data dictionary. Subsequent detailed 
design activities associated with the product are frequently conducted in an iterative 
process with unit code development (e.g., screen formats, interfaces, report format 
definitions). 

The design information is incorporated into the design book and carried forward with 
other design information as part of the as built documentation package. 

Representatives of the OPR shall participate throughout the Design and Development 
Phase. This participation is generally facilitated through the use of passive and/or active 
prototypes. Joint Application Design (JAD) sessions, and technical reviews. These 
activities are sponsored and conducted by the TMIS Office, the OPR, and the contractor 
responsible for the product's development. 

Early in the Design and Development Phase, the requirements for user training, 
production support, and user documentation are established with the OPR as the 
representative of the end users. Preparation for training, user support, and user 
documentation is incorporated into the implementation plan/schedule. 

4.2.1 .2 ACQUISITION OR DEVELOPMENT PROCESS 

The product is parceled into appropriate units (modules) in order to facilitate effective 
development and associated technical reviews. The specific activities associated with 
this development effort are highly dependent upon the nature of the product. A product 
involving the acquisition of commercial-off-the-shelf (COTS) software, for example, 
will follow different development processes than does a product that is entirely 
developed by a contractor using existing TMIS software and hardware. 

For products developed by a contractor, a requirements traceability matrix for the entire 
RDD is established at this time and included in the product’s design book, which is 
carried forward as part of the as built documentation package. This matrix is used 
throughout the unit code development process to link developed units with their 
associated requirements. 

4.2.1 .3 TEST PLAN AND SCRIPT PREPARATION PROCESS 

An integral part of the Design and Development Phase is the definition and development 
of the various test scripts associated with testing and validating the product. These 
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scripts may include unit tests, application and system integration tests, benchmark tests, 
and stress tests. As part of the preparation of the scripts, a general approach or plan and 
testing instructions are also prepared. 

A primary objective is to automate the testing activity to the greatest extent possible. 

This objective is accomplished through the definition of testing scenarios that 
demonstrate the capability of the product to perform in the environment defined by the 
user, the translation of those scenarios into test scripts (i.e., the definition of specific 
key-strokes or actions required to execute the test scenarios), and conversion of the test 
scripts into the technical language of the specific automated testing tool chosen to 
support the product’s development. 

Detailed information concerning the development of test scripts, TMIS automated testing 
tools, and TMIS test script libraries is contained in the TMIS System Certification 
enabling procedure. 

The test scripts are carried forward with other design information as part of the 
documentation package. 


4.2.1 .4 UNIT TEST PROCESS 

Unit tests are executed and results of the tests are recorded by the contractor responsible 
for developing the product. Unit test scripts are executed by the contractor responsible 
for developing the product, and results of the tests are recorded. The results of each test 
are reviewed by the development team, and discrepancies are either addressed by 
appropriate corrective actions or carried forward as a discrepancy. Unit tests are then 
re-executed against corrected units to verify that identified discrepancies have been 
properly resolved. 

The unit test scripts and the results of the unit tests are carried forward with other design 
information as part of the documentation package. 


4.2.1 .5 PRELIMINARY BENCHMARK TEST PROCESS 

Benchmark tests are included in the development life cycle of a product as a means to 
measure the impact of changes on the performance of the product, as well as to establish 
an initial benchmark performance measurement for the product. These measurements 
include, but are not limited to, CPU time consumed, I/Os expended, wall-clock 
execution time, and memory usage. 

During the unit code development, preliminary benchmark tests are executed to validate 
the test scripts and determine the performance characteristics of the units being 
developed. The results of these tests may be compared with previous benchmarks of the 
product to determine the impact of changes that have been made to the product. The 
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results of these tests may also be compared against anticipated results and/or established 
TMIS standards and guidelines. Problems identified during these tests are to be 
addressed with appropriate corrective actions and follow-up testing. 

Benchmark tests run during the development phase of the life cycle are usually run in the 
development environment of the TMIS host. This differs from the final benchmark tests 
executed later in the life cycle; final benchmark tests are usually executed in a dedicated 
test environment without interference or contention with any other product. 

The benchmark test process is further discussed in the TMIS System Certification 
enabling procedure. 


4.2.1 .6 PRELIMINARY STRESS TEST PROCESS 

Stress tests are conducted against an emerging product to measure the product’s 
performance in response to simulated loads. Such loads may include concurrent user 
access of the product, “worst case” data base sizing, concurrent execution of processes 
within the product, communication network loading, etc. 

Similar to the benchmark test, the stress test is used to identify performance 
characteristics of the developing product, and/or to identify performance concerns 
associated with the product. The results of these tests may be compared against 
anticipated results and/or established TMIS standards and guidelines. Problems 
identified during these tests are to be addressed with appropriate corrective actions and 
follow-up testing. 

The stress test process is further discussed in the TMIS System Certification enabling 
procedure. 


4.2.2 DESIGN AND DEVELOPMENT PHASE REVIEWS 

Throughout the development process, the TMIS Office, the OPR, and the contractor 
responsible for developing the product participate in technical reviews of the developing 
product. These technical reviews focus on various aspects of the developing product 
including data base design conformance to TMIS standards, effective coding techniques, 
comparison of “as built” to “as-required,” detailed screen/report specifications, results of 
code walk-throughs, functional demonstration of emerging capabilities, etc. 

One key review early in the Design and Development Phase is the Architecture Design 
Review. This review is conducted when the appropriate design media and 
documentation have been completed; reviewed by appropriate parties; and approved by 
the TMIS Office, OPR, and contractor representatives. This review is the point where 
impacts of the design upon respective functional organizational responsibilities and other 
TMIS products and resources are determined and reconciled. 
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4.2.3 DESIGN AND DEVELOPMENT PHASE DOCUMENTATION 
4.2.3. 1 IMPLEMENTATION SCHEDULE 

An implementation schedule to be used in managing and providing implementation 
visibility shall be required. 

The implementation schedule shall contain a level of activity and milestone detail that 
can be mapped to the processes, reviews, and outputs identified in the TMIS Life Cycle 
Process - Process Flow Diagram (Figures 4.0—1 and 4.0-2). The implementation 
schedule is an activity schedule showing tasks, related flow times, and task 
dependencies. 

The implementation schedule is the tool used by the project team managers and members 
to manage and monitor progress of the project. It is at this level that specific reviews, 
approvals and deliverables are tracked and responsibilities identified. Details and 
schedule templates are included in the TMIS Life Cycle Process Management enabling 
procedure. 


4.2.3.2 DESIGN BOOK 

During the Design and Development Phase of the TMIS life cycle, a design book is 
established. This design book is regarded as a dynamic document in that information 
associated with each subsequent phase or activity in the development of the product is 
added to the document (e.g., logical design, physical design, unit code test results). The 
contents of this document are the subject of the various technical reviews conducted 
throughout the remainder of the product’s life cycle. 

The format for the design book is contained in the TMIS Documentation Management 
enabling procedure. 

4.2.3.3 TEST PLAN SCRIPTS AND PARAMETERS 

The test scripts provide the test code procedures and specific test scenario parameters and 
instructions to be applied to the testing of a product. They include unit tests, installation 
tests, application and system integration tests, benchmark tests, and stress test scenarios. 
The test scripts form the plan for the overall testing and certification approach. 

The TMIS Documentation Management enabling procedure contains the formats for the 
development of the test scripts. 

4.2.3.4 USER DOCUMENTATION 

User documentation in the form of handbooks, reference manuals, and/or user’s guides 
provide instructions to the end user on how to effectively use the product. They include 
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detailed instructions covering start-up, diagnostics, help, screen flows, error recovery, 
and other information that enables the user to interface with the product. All user 
documentation materials shall be reviewed by the appropriate parties and approved by 
TMIS-O, OPR and developer. 

The TMIS User Documentation Style Guide contains the standard for the development of 
user documentation. 


4.2.3.5 OPERATIONS MANUAL 

The operations manual provides system operators and administrators with procedures 
required to operate the product. It includes monitoring procedures, backup and recovery 
procedures, scheduled jobs required for normal operation of the application, safety and 
security procedures, and output distribution procedures associated with the product. The 
specific instructions for installing the product into the host production environment are 
included in the operations manual. All Operations Manuals shall be reviewed by the 
appropriate parties and approved by TMIS-O, OPR and developer. 

The TMIS Host System Standards enabling procedure provides the TMIS system 
standards for application developers (e.g., system configuration, general operating 
procedures, disk space allocation and management guidelines). An outline for an 
operations manual is provided in the TMIS Documentation Management enabling 
procedure. 


4.2.3.6 TRAINING MATERIALS 

Training materials provide the necessary lesson plans, presentation materials, and student 
handouts for conducting a practical course on the use of the product. The requirement 
for and scope of training materials will be determined by the TMIS Office in concert 
with the OPR. All training materials shall be reviewed by the appropriate parties and 
approved by TMIS-O, OPR and developer. 

The TMIS User Documentation Style Guide contains the standard for the development of 
training materials. 


4.2.3.7 UNIT TEST RESULTS 

The unit test results show the outcome of the scripts executed during the unit tests. The 
results are summarized on a cover sheet listing the units tested and any subjective 
comments and conclusions, followed by the collection of the scripts documenting actual 
results with the pass/fail status and execution times for the scripts. 


4-8 


SSP 30542 Revision A 


4.3 TEST PHASE 

The objective of the Test Phase is to accomplish the following: 

(1) Functionally validate the procured or developed product or data base application as 
satisfying the documented requirements. 

(2) Measure and accept the product’s performance via benchmark and stress test analysis. 

(3) Certify that the product is ready for installation into the TMIS production 
environment. 

It is also at this point, using the installation instructions, that the product or data base 
application code is migrated into the test environment and placed under configuration 
control disciplines. 


4.3.1 TEST PHASE PROCESSES 

4.3.1. 1 INSTALLATION TEST PROCESS 

The installation test involves two primary activities: 

(1) Preparing the instructions for installing the software into the integration environment. 
These will be the same instructions used eventually to install the software into the 
production environment. 

(2) Testing the installation instructions. 

The installation test is a simulation of the production installation procedures. The results 
of the installation test are reviewed by the development team and discrepancies are 
addressed by appropriate corrective actions. The installation test is then re-executed to 
verily that identified discrepancies have been properly resolved. 

The development team is responsible for execution of the installation test. 

Installation procedures and the results of the installation test are carried forward with 
other design information as part of the as built documentation package. 


4.3.1 .2 PRODUCT OR APPLICATION INTEGRATION TEST PROCESS 

Upon the successful completion of all unit code tests, the emerging product is subjected 
to product integration testing. At this stage all units of the emerging product are brought 
together and tested as a single entity. The purpose of this integration test is to ensure that 
all units function in concert with each other. 

Product integration testing involves both those units which were modified or newly 
developed during the product’s life cycle as well as existing units of the product which 
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were not modified. The integration tests ensure that modified units function in concert 
with existing, unmodified units. 

The results of the integration test are reviewed by the development team and 
discrepancies are addressed by appropriate corrective actions. Appropriate tests are then 
re-executed to verify that identified discrepancies have been properly resolved. 

The development team is responsible for conducting the product integration tests. Test 
scripts and test results are carried forward with other design information as part of the as 
built documentation package. 


4.3.1 .3 SYSTEM INTEGRATION TEST PROCESS 

The system integration test is similar to the product integration test except that the 
objective is to ensure that the emerging product, as a single entity, executes in concert 
with other TMIS production products. This integration test includes verification that the 
emerging product interfaces appropriately with other TMIS production products as 
designed. Additionally, this test ensures that the emerging product does not negatively 
interfere or contend with any other production products or with the TMIS host system. 

The results of the system integration test are reviewed by the development team and 
discrepancies are addressed by appropriate corrective actions. Appropriate tests are then 
re-executed to verify that identified discrepancies have been properly resolved. 

The development team is responsible for conducting the system integration tests. Test 
scripts and test results are carried forward with other design information as part of the as 
built documentation package. 


4.3.1 .4 BENCHMARK TEST PROCESS 

Benchmark tests are constructed to measure performance of an application in order to 
establish that the product, as designed and developed meets the stated performance 
requirements. The performance measurements provide a baseline of statistics against 
which future software enhancements can be measured or for use in measuring results of a 
regression test. 

Benchmark testing is performed in the test environment, that is, the same mainframe 
using the same operating system and support software that will be used in the production 
environment. No other applications will be operating during this test. 

Benchmark test scenarios are constructed from the unit and/or integration test scenarios 
by the test analyst and are maintained in the test library. These scripts encompass all 
interactive capabilities of the application. 

Test reports and supporting documentation such as test result logs, problem report 
descriptions, and problem report resolutions are also forwarded to the test library. 
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4.3.1 .5 STRESS TEST PROCESS 

Stress testing is performed on selected application software to determine what effect user 
workload has on performance and to determine when increasing user workload causes an 
overload condition to occur. 

The stress test is conducted following a successful benchmark test. A portion of the 
benchmark script will be run to create real-time loading conditions for the application. 
The stress test will usually be executed using the same data base and environment 
configuration used in the benchmark testing. A portion of the script will be extracted, 
refined, and executed in multiple sessions to simulate various user workloads. 

Statistics are gathered from these stress tests in an attempt to locate potential bottlenecks 
in the application processing configuration. Application and system performance tuning 
is performed by developers to eliminate bottlenecks. Tests are repeated as required. 
Applications must pass the stress test criteria before being installed into production. 

Stress test scripts must be selected with a high degree of participation by the OPR 
representing the user community. The OPR as the interface with the user determines the 
percentage of utilization of the functional capabilities so that the stress test scripts can 
adequately reflect the user’s perception of anticipated utilization. 

Stress test scenarios, cases, and procedures are prepared by the test analyst and are 
maintained in the test library. Test reports and supporting documentation such as test 
result logs, problem report descriptions, and problem report resolutions are also 
forwarded to the test library. 


4.3.1 .6 CERTIFICATION PROCESS 

The certification process provides security certification and system certification. 

The security certification process determines whether the application meets the 
documented and approved system security specifications. It also validates that the results 
of the integration test demonstrate that the security provisions are adequate for the 
application’s protection. 

Following the installation tests, but prior to the Operational Readiness Review (ORR), 
the test scripts, test logs, and test data are reviewed for completeness. 

The system certification process validates that a comprehensive set of tests; including the 
unit, installation, product or application integration, system integration, benchmark, and 
stress tests; were conducted and documented. The primary focus is to ensure that 
requirements are fully tested and that life cycle methodology standards and guidelines 
were followed. 

The TMIS implementation philosophy emphasizes the importance of having 
user-representatives intimately involved throughout the requirements, design and 
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development, and testing phases. Based upon this involvement throughout the life cycle, 
the OPR certifies that the application meets the specified needs. 


4.3.2 TEST PHASE REVIEWS 

As the various testing processes occur during the Test Phase, a number of reviews are 
held to assess the results and to determine if corrective action is required. During this 
phase the software undergoing test is under configuration management control. 

Problems and discrepancies occurring during these tests are identified and recorded 
according to the procedures specified in the TMIS Problem Reporting enabling 
procedure for tracking and resolution. Likewise, software changes must follow the 
established configuration management disciplines for incorporating changes into 
controlled software. 


4.3.3 TEST PHASE DOCUMENTATION 
4.3.3. 1 INTEGRATION TEST RESULTS 

Results of the installation tests, product or application integration tests, and the system 
integration tests are documented. These tests are performed prior to the release of any 
COTS, application, or major system software product. 

The documentation contains the pass/fail test results for the enhancements included with 
the release followed by the pass/fail test results for tests of unmodified portions of the 
product or application that were required by the release. 


4.3.3.2 BENCHMARK TEST RESULTS 

The actual results and subjective comments and conclusions of the benchmark test are 
recorded including an analysis of the performance statistics (e.g., CPU time, I/Os) 
associated with the execution of each transaction included in the benchmark test. This 
analysis includes both interactive execution transactions and batch execution 
transactions. 


4.3.3.3 STRESS TEST RESULTS 

The actual results and subjective comments and conclusions of the stress test are 
recorded including an analysis of the stress test with emphasis on analysis of 
system/application performance based on simulated “normal” user workloads and “worst 
case” workloads. 
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4.3. 3. 4 TEST PLAN AND TEST REPORT 

A test plan is prepared for each release and includes proposed testing techniques and 
approaches together with test scripts, test scenarios, expected results, parameters, and 
instructions. 

Upon completion of all testing, a consolidated report is prepared documenting results 
from the various tests described above and as compared to the test plan. 

The formats for the contents of the test plan and the test report are detailed in the TMIS 
Documentation Management enabling procedure. 


4.3.3.5 SECURITY CERTIFICATION 

Security controls are an integral part of the design of products and data base applications. 

TMIS Office Security is responsible for issuing a Security Certification statement 
indicating that the application, product, or tool is in compliance with NASA and other 
federal policies, regulations, and standards covering automated information security. 

If conditions exist that prevent the issuance of the Security Certification, a Conditional 
Certification may be issued and the product placed in production operation with a 
suspense date for resolution. 

The requirements for security of products and data base applications are found in SSP 
30541, TMIS Security Requirements document. 

The policy regarding security certification is stated in TMIS Procedure 90-01, Security 
Certification of Sensitive Applications. 


4.4 DEPLOYMENT PHASE 

The objective of the Deployment Phase is to assemble, validate and place under 
release/configuration control the delivered and certified product and all of the required 
supporting documentation (e.g., user documentation, training materials, operation 
instructions). A formal Operational Readiness Review is conducted by the TMIS Office 
with “go-ahead” approval required before installation and deployment of the product is 
initiated. This phase is concluded when successful installation and deployment is verified 
and documented. 

4.4.1 DEPLOYMENT PHASE PROCESSES 

4.4.1. 1 VERSION DESCRIPTION DOCUMENT (VDD) PREPARATION 

During the Version Description Document (VDD) preparation process, the hardware and 
software component inventory is assembled into a single document for each product 


4-13 



SSP 30542 Revision A 


release. Requirements and problem reports satisfied by the release, any outstanding 
discrepancies, the production installation instructions, and the deployment plan are 
compiled and added to the document. VDD contents are described in the TMIS 
Documentation Management enabling procedure. 

VDD materials are routed for review by all TMIS-IC support services and are then 
updated and submitted for approval by the TMIS-IC Internal Change Board. The VDD 
materials are forwarded to the TMIS-IC Configuration Management (CM) library. 


4.4.1 .2 ASSEMBLE OPERATIONAL READINESS REVIEW (ORR) MATERIAL 

During the ORR material assembly process, information from the requirements 
documents (RDD or DFRD), user documentation, training materials, operations manual, 
test repons, certifications, and VDD are summarized and then compiled into briefing 
charts for each product. Detailed test results are available upon request, but are not part 
of the ORR material. 

The materials for individual products are then combined into an overall blockpoint 
release package, which includes a table of contents and the Release Approval signoff 
form. This briefing material is made available by electronic distribution for use at the 
remote NASA sites. 

Prior to conducting the formal ORR, the briefing material is reviewed by the developer 
and TMIS Office management. ORR attendees are notified approximately one week prior 
to the ORR date. 

The materials prepared for the ORR package are forwarded to the CM library. 


4.4.1 .3 MIGRATION TO PRODUCTION 

Following ORR approval, the production installation instructions included in the VDD 
for each of the products are executed. Libraries and databases are reviewed to ensure that 
the operations were performed correctly. 


4.4.1 .4 DATA BASE CONVERSION AND/OR INITIAL DATA LOADING 

If existing data is associated with the application or product being deployed, then a data 
conversion/loading process must be executed. This process usually takes the form of 
either converting an existing data base for use by the new product, or loading an initial 
set of data into the data base of the new product. Execution of this process may be 
performed as part of the deployment phase or may be executed at a later time after 
deployment as part of the operational phase. In either case, software required to facilitate 
this execution should be included in the life cycle phases at the same time as the 
application or product. 
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4.4.1. 5 PRODUCTION VERIFICATION TEST 

Following the migration of the production data base application or product, a verification 
process is followed that may involve running production verification scripts, running 
procedures to verify data base conversions, and manually examining libraries. The 
purpose of the verification test is to ensure that the software has been properly installed 
in the production TMIS environment. 

A production verification report is produced by the verification team and is forwarded to 
the CM library. 

4.4.2 DEPLOYMENT PHASE REVIEWS 

The Operational Readiness Review ensures that the prepared releases of products are 
ready for production use. The TMIS-IC and developer team brief the TMIS Office using 
the contents of the ORR package. 

At the review, the functional area representatives (system certification, site support, 
security, training, user documentation, capacity planning, operations, and independent 
product assurance) certify that no problems or outstanding issues remain with regard to 
the production use of the application or product. The deployment schedule is presented 
and TMIS Office approval is recommended. 

Signatures on the TMIS Release Approval form are provided by TMIS Office for each 
product approved for deployment. The completed form is forwarded to the CM library. 

The formats for the ORR presentation and the TMIS Release Approval form are provided 
in the TMIS Documentation Management enabling procedure. 


4.4.3 DEPLOYMENT PHASE DOCUMENTATION 
4.4.3. 1 VERSION DESCRIPTION DOCUMENT (VDD) 

The primary purpose of the VDD is to identify the hardware and software components 
that comprise the product. In addition, it also includes the requirements and problem 
reports satisfied by the release, any outstanding discrepancies, the production installation 
instructions, and the deployment plan. 

The TMIS Documentation Management enabling procedure contains the standard for 
preparing Version Description Documents. 


4.4.3.2 OPERATIONAL READINESS REVIEW (ORR) PACKAGE 

The ORR package contains the briefing materials to be reviewed for TMIS Office 
approval prior to releasing software into the production environment. It includes a 
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statement of the requirements and problem reports satisfied by the release, a summary of 
the unit, integration, benchmark, and stress tests, a review of the certifications received 
for the product, any outstanding discrepancies, and a brief review of the status of support 
tasks performed in preparing the product for deployment. 

The TMIS Documentation Management enabling procedure contains the format to be 
used in preparing the ORR package. 


4.5 OPERATIONAL PHASE 

The Operational Phase extends over the ongoing production operation of the product. 
Procedures for performance monitoring and product maintenance are established for this 
phase. Sustaining engineering tasks related to product upgrades and/or problem 
resolution are performed. As changes to the product are required, the changes are 
documented as a requirement and cycled back through the life cycle process. 


4.5.1 TRAINING 

User training is delivered as part of the Operational Phase in accordance with the 
implementation plan/schedule that was developed under the design and development 
process. 


4.6 SUPPORTING FACILITIES 
4.6.1 TEST LIBRARY 

The test library is a collection of all current test cases and procedures used in unit, 
integration, installation, benchmark, and stress testing. In addition, it contains completed 
test results, installation instructions, and test reports. 

Following an initial release of software, a complete set of tests is stored in the library. A 
data base of test cases and procedures is maintained for each application or product by 
test phase. 

When software enhancements are made, the library of tests is reviewed to select tests that 
can be adapted for testing the enhancement, as well as tests that may be used for 
regression testing. 

Following software enhancement releases, modified test cases and procedures are 
forwarded and stored in the test library. 

Following each blockpoint release, the updated summary of test cases, procedures (by 
application and phase), and a detailed listing of test cases and procedures, is produced. 
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4.6.2 AS BUILT DOCUMENTATION 

Product documentation is prepared in working form throughout the life cycle. As 
documentation and data are required, they are extracted from the working set of 
documentation and appropriately formatted and processed. At the point of ORR 
approval, all documentation that represents the as built version of the production release 
is collected and put under configuration control. 


4.6.3 TMIS CONFIGURATION MANAGEMENT FILES 

The TMIS-IC Configuration Management organization retains both hard copy and 
electronic media copy of the TMIS baselined product documentation. CM is the 
repository for controlling such documentation as the Version Description Document, as 
built documentation, etc. 

Electronic media storage of TMIS baselined product software is also controlled or 
established by the TMIS— IC Configuration Management organization. 


4 


17 



Requirements Design and Development Phase Test Phase 

Phase (Development Environment) (Test Environment) 



8 


4.0-1 TMIS LIFE CYCLE PROCESS - PROCESS FLOW DIAGRAM 

























SSP 30542 Revision A 


5.0 IMPLEMENTATION OF THE TMIS LIFE CYCLE PROCESS 

5.1 IMPLEMENTATION TEAMS 

Implementation teams are established for each development or acquisition task, with 
representation assigned from the functional organizations (e.g.. Data Administration, 
Information Systems, System Certification, Operations, User Documentation 
Management, Engineering, Training, Site Support, Independent Product Assurance). 

The primary development organization provides the technical management of the project 
as well as the principle development or integration staff. A TMIS Office interface is 
assigned to each implementation team as the project manager. 

The implementation team managers are responsible for accomplishing start-to-finish life 
cycle project tasks, using assigned functional resources. 

Functional organization representatives on the implementation teams are assigned to 
support the implementation tasks and verify that functional disciplines and procedures 
have been satisfied. 

Further details on implementation teams is provided in the TMIS Life Cycle Process 
Management enabling procedure. 


5.2 LIFE CYCLE PROCESS MODEL - PROCESS FLOW DIAGRAM 

The TMIS Life Cycle Process Model-Process Flow Diagram (Figures 4.0-1 and 4.0-2) 
is intended to serve as a guide or template for managing a project. The flow diagram 
identifies and interrelates a basic set of tasks and outputs from which a specific project 
plan and schedule can be constructed. It is recognized that each project will have unique 
characteristics, therefore, the template is a guide to preparing a specific project plan. 
Tasks and outputs may be added to provide appropriate management control and 
visibility. Likewise, some template items may not be applicable to the project and may be 
omitted as documented in the requirements document. 


5.3 DOCUMENTATION 

Product documentation is prepared in working form throughout the life cycle phases. At 
appropriate process steps, the documentation is finalized and formatted as required for 
baselining, distribution, and retention. Conceptually, the documentation process is a 
sequential stacking of the project data into one final collection during the implementation 
phases, as illustrated in Figure 5.3—1 , TMIS Life Cycle Process— Documentation Build 
Up. As documentation and data are required, they are extracted from the collection. 
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appropriately formatted, and processed. At the point of ORR approval, all 
documentation that is key to defining the product release is collected and put under 
configuration control. This set of documentation represents the as built documentation 
for the production release of the product. 


5.4 SCHEDULES 

An activity schedule to be used in managing and providing implementation visibility 
shall be prepared. The schedule contains a level of activity and milestone detail that can 
be mapped to the processes, reviews, and outputs identified in the TMIS Life Cycle 
Process-Process Flow Diagram (Figure 4.0-1 and 4.0-2). The required project 
schedules are detailed in the TMIS Life Cycle Process Management enabling procedure. 


5.5 LIFE CYCLE PROCESS DOCUMENT STRUCTURE 

Documentation related to the description and establishment of the life cycle process for 

products is segregated into three levels of administration and control, as shown in 

Figure 5.5-1, TMIS Life Cycle Process Document Structure: 

— Level 1 SSFP/TMIS Baselined Documents , including the TMIS Life Cycle 

Process Document, establish Program wide standards and direction. This level of 
documentation shall be maintained by the TMIS Control Board (TCB). 

— Level 2 TMIS Enabling Procedures support the implementation of the life 

cycle process to current and future projects and tasks. These procedures shall be 
established and maintained in the TMIS Policies and Procedures Manual. 

— Level 3 Developer/Contractor’s Operating Procedures implement day-to-day 

processes and instructions within the developer’s organization to meet the 
requirements established by the baselined documents and enabling procedures. This 
level of documentation is maintained as pan of the contractor’s operating procedures 
and is unique to the developer/contractor. 


5.5.1 SSFP/TMIS BASELINED DOCUMENTS 

The set of SSFP/TMIS baselined documents that establish Programwide standards and 
direction are: 

— TMIS Information Engineering Methodology (SSP 30535) 

— TMIS User Documentation Style Guide (SSP 30536) 

— TMIS Application Development Standards (SSP 30543) 

— TMIS Security Requirements (SSP 30541) 

— SSFP Data Naming Standards (TSS 30551) 
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5.5.2 TMIS ENABLING PROCEDURES 

A set of TMIS-wide enabling procedures implement and support the on-going life cycle 
process of current and future projects and tasks. The procedures provide direction to the 
developer organizations and form the basis for preparation of their day-to-day operating 
procedures. These enabling procedures are established and maintained in a TMIS 
Policies and Procedures Manual by the TMIS Office. 

Enabling procedures specifically related to this life cycle process include: 

— TMIS Life Cycle Process Management - This procedure sets forth the basic project 
management practices to be employed. It addresses implementation teams, team 
members’ responsibilities, schedules, and deliverables. 

— TMIS System Certification - This procedure sets forth the system certification and 
testing practices to be employed. It addresses testing, the test library, and security 
validation. 

— TMIS Configuration Management and Product Assurance — This procedure sets forth 
the configuration management and product certification practices to be employed. It 
addresses software, documentation, hardware, product versioning, and release 
management. 

— TMIS Documentation Management - This procedure addresses life cycle 
documentation (types and formats), document preparation and distribution, and the 
document library. 

— TMIS Host System Standards - This procedure sets forth the guidelines to be 
followed when developing a data base application or implementing a product in the 
TMIS host environments. 

— TMIS Problem Reporting - This procedure establishes the process for TMIS users to 
report a failure, malfunction, degradation, deficiency, or deviation against a TMIS 
production system or application. The procedure applies to all SSFP TMIS primary 
and secondary users and to any organization or activity that has a formal agreement 
for unique or specialized support services from TMIS. 


5.5.3 DEVELOPER/CONTRACTOR OPERATING PROCEDURES 

Operating procedures that implement day-to-day processes and instructions will be 
maintained within the developer’s organization to meet the requirements established by 
the baselined documents and enabling procedures. This level of documentation is 
maintained as part of the contractor’s unique operating procedures. 
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APPENDIX A ABBREVIATIONS AND ACRONYMS 


CM 

Configuration Management 

COTS 

Commercial-Off-The-Shelf 

CPU 

Central Processing Unit 

CR 

Change Request 

DFRD 

Detailed Functional Requirements Document 

ICD 

Interface Control Document 

IDD 

Interface Description Document 

I/O 

Input/Output 

JAD 

Joint Application Design 

NASA 

National Aeronautics and Space Administration 

N/A 

Not Applicable 

OPR 

Office of Primary Responsibility 

ORR 

Operational Readiness Review 

PFM 

Program Function Model 

PR 

Problem Report 

RDD 

Requirements Definition Document 

SSCB 

Space Station Control Board 

SSFP 

Space Station Freedom Program 

SSFPO 

Space Station Freedom Program Office 

SSP 

Space Station Program 

TBD 

To Be Determined 

TCB 

TMIS Control Board 

TIEM 

TMIS Information Engineering Methodology 

TMIS 

Technical and Management Information System 

TMIS-IC 

Technical and Management Information System-Integration 
Contractor 

VDD 

Version Description Document 
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APPENDIX B GLOSSARY 


APPLICATION SOFTWARE 

Customized software component developed for use within SSFP by the TMIS— IC or 
other developer. 

AS BUILT 

The baselined configuration (including documentation and software) of the product or 
data base application as released into production. 

BASELINE 

A configuration identification document or set of documents formally designated and 
fixed at a specific time during a configuration item’s life cycle. Baselines, plus approved 
changes from those baselines, constitute the current configuration identification. 

BLOCKPOINT 

A scheduling technique whereby a collection of developed, acquired, customized, 
integrated, and/or maintained software and/or hardware items are released into 
production on a single day. 

CERTIFICATION 

The process by which a TMIS release is determined to be acceptable from functional, 
technical, and security points of view. 

COMPONENT 

One of the three parts m akin g up an information system: hardware, software or 
operational procedures, or a portion of a higher level component of the same type. 

CONFIGURATION MANAGEMENT 

The process of maintaining control of the TMIS configuration of hardware, software, and 
communications components. 

COTS 

Commercial-off-the-shelf products acquired for the purpose of integration into the 
TMIS environment. 

CUSTOMIZING 

Enhancement and/or modification of COTS products, prior to installation in the 
production TMIS environment, to meet the requirements of the TMIS user community. 

EMERGENCY 

A condition in which a group of TMIS users is prevented from doing essential Space 
Station Freedom work because of a TMIS malfunction of some kind. Must be addressed 
on a higher priority than any other TMIS activity. 
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ENABLING 

The documentation that establishes and implements the life cycle process. It is used 
rather than the word “implementing” because of the use and implied meaning of 
“implementation” in the life cycle process. 

FORMAL TEST 

A test conducted in accordance with test plans and procedures approved by NASA and 
witnessed by an authorized NASA representative to verify that the product satisfies 
specified requirements. 

IMPLEMENTATION 

The definition of this term includes requirements determination and product specification 
functions as well as the development, test, deployment, and on-going operation and 
sustaining engineering functions. 

INCREMENT 

The stage of Space Station Freedom development that a TMIS release is designated to 
support. 

INFORMAL TEST 

Any test conducted by a developer but not witnessed by an authorized NASA 
representative. These tests use detailed test cases and procedures that were not previously 
approved by NASA but are available for NASA review upon request. 

INTEGRATION 

Adaptation of developed or COTS software or hardware components for use with the 
TMIS suite of systems. Integration may have an implicit requirement for optimizing the 
components’ performance in relation to the full TMIS system. , 

MAINTENANCE 

Enhancements, modifications, and fixes to production software, whether they be TMIS 
developed or COTS customized. 

PRODUCT 

Data base applications, or system software, hardware, or network components which are 
procured (COTS) or developed for use in TMIS. 

PRODUCT ASSURANCE 

The process by which management assures that high quality is built into the components 
of the TMIS suite of systems. 

PROGRAMWIDE DATA BASES 

All data bases to be shared among SSFP levels I, n, and IQ; NASA centers; other 
organizations; and International Partners. 


B - 2 



SSP 30542 Revision A 


PROTOTYPE 

A model depicting a proposed application that is used to define and/or clarify user 
requirements. 

REGRESSION TEST 

Tests conducted on portions of an application that have not changed. These tests are 
conducted when other related software enhancements are applied. They are run to ensure 
that test cases and procedures produce the same results as before the enhancement. 

SOFTWARE 

Computer code, including firmware, and its associated documentation. For the purposes 
of this procedure, software will be categorized as either developed or COTS system 
software or data base application software. 

SOFTWARE ENHANCEMENT 

Any new operational capability added to previously operational software. Typically, this 
software will have been entered into the TMIS Product Baseline and is under control of 
the TMIS CM organization. 

SYSTEM SOFTWARE 

Software component that provides basic, generic computing capabilities such as the 
operating system, network, and data base capabilities. 

TESTING 

The process of exercising or evaluating an information system or component by either 
manual or automated means to demonstrate that it satisfies specified requirements or to 
identify differences between expected and actual results. 
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